Through recent technological advances, the ability exists today to exchange voice communications over a packet network, and this has begun to revolutionize the telecommunications industry. Specifically, a customer who has Internet access can now make telephone calls through the packet network, in this way bypassing the existing communications infrastructure and consequently avoiding the hefty long distance fees charged by incumbent local exchange carriers.
In one scenario, to be able to place voice-over-packet (usually referred to as VoIP) telephone calls, the customer may purchase a specialized telephone handset that has certain features characteristic of a networked device, such as the ability to exchange packets over a packet network. Alternatively, the customer can utilize a conventional telephone fitted with an analog terminal adapter (ATA) that provides the necessary voice-to-packet translation and vice versa. Yet a third option has become available, whereby the same computer that is used to gain Internet access is also used as a telephony device by running specialized software and utilizing the computer's built in microphone and speaker. In this last scenario, the computer runs what can be referred to as a “soft client”. The advantages of a soft client are principally in the areas of practicality, reconfigurability and cost. These advantages flow from exploiting the same Internet connection to support both an Internet access tool (e.g., a web browser) and the soft client.
Unfortunately, current soft client implementations suffer from several drawbacks, at least one of these being due to the very fact that the same Internet connection is shared by both a soft client and a web browser. Specifically, where a VoIP call may require special treatment by routers in the packet network (e.g., from a security, bandwidth or priority perspective), such treatment is not achievable since the computer running both the soft client and the web browser communicates using a single IP address. Stated differently, the packet network cannot make the distinction between VoIP traffic and non-VoIP traffic on the basis of a packet's IP address.
To remedy this situation, some proposals have called for the use of a dedicated port for VoIP traffic that would be appended to the IP address. Routers in the network would then need to recognize the port when performing a forwarding operation. However, this solution is not universal, since many routers are configured to ignore the port and instead perform routing solely on the basis of a packet's 32-bit destination IP address.
Thus, it would be desirable to overcome the difficulties mentioned above so as to allow VoIP calls to be differentiated in the packet network, in order to meet certain specific security, bandwidth or priority requirements, for example.